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Abstract 

The Bandwidth Enabled Flight Operations 
project is a research effort at the NASA Ames 
Research Center to investigate the use of satellite 
communications to improve aviation safety and 
capacity. This project is a follow on to the 
AeroSAPlENT Project, which demonstrated 
methods for transmitting high bandwidth data in 
various configurations. For this research, we set a 
goal to nominally use only 10 perc ent of the 
available bandwidth demonstrated by 
AeroSAPlENT or projected by near-term 
technology advances. 

This paper describes the results of our 
research, including available satellite bandwidth, 
commercial and research efforts tc provide these 
services, and some of the limiting factors inherent 
with this communications medium It also 
describes our investigation into the needs of the 
stakeholders (Airlines, Pilots, Cabin Crews, ATC, 
Maintenance, etc). The paper also describes our 
development of low-cost networked flight deck and 
airline operations center simulations that were used 
to demonstrate two application areas: Providing 
real time weather information to the commercial 
flight deck, and enhanced crew monitoring and 
control for airline operations centers. 

Introduction 

The Bandwidth Enabled Flight Operations 
(BEFO) project stemmed from the results of the 
AeroSAPlENT Project (Aeronautical Satellite 
Assisted Process for Information Exchange through 
Network Technologies). AeroSAPlENT [1] was 
based at the NASA Glenn Research Center (Ohio), 
and included collaboration with NASA Ames (CA), 
NASA Dryden (CA), and the Tinker Air Force Base 
in Oklahoma. 


The AeroSAPlENT project demonstrated 
technology that was able to support a high 
bandwidth computer network connection between a 
flying aircraft and a ground station via a satellite. A 
DC-8 research aircraft was used for the flight tests, 
through which in-flight network communications 
technology was used to enact several simultaneous 
applications at a high bandwidth data rate. 

Based on these results, the Bandwidth Enabled 
Flight Operations (BEFO) project was initiated 
within the Computational Sciences Division at the 
NASA Ames Research Center. The high level goal 
of the project was to investigate new ways in which 
this technology could be applied to improve airline 
safety and capacity (the ability to move more 
aircraft and passengers through the airspace 
system). Our initial development direction and 
goals were to: 

• Understand the current capacity and 
limitations of air-ground bandwidth 
within the commercial aviation industry. 

• Understand what applications potential 
users (Airlines, Pilots, Cabin Crews, 
ATC, Maintenance) envisioned to use 
with increased bandwidth. 

• Develop a prototype cockpit 
environment in which new concepts 
could be easily evaluated. 

• Collaborate with other groups working 
on technologies that could be easily 
integrated into this environment. 

The work described in this paper was 
performed between July 2001 and February 2002. 
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Aviation Bandwidth Issues 

Transmission Speed and Capacity 

Our initial research efforts were to understand 
the capabilities of current aviation networking 
technology. Two examples of current aviation 
communication networks include CPDLC [2] and 
the FAA Capstone Project [3]. CPDLC (Controller 
Pilot Datalink Communications) is an effort to 
support both voice and data transmissions to and 
from the cockpit, with non-critical information 
exchanges being sent over the data line. This 
system operates at 2.4 Kbps data and 9.6 Kbps 
voice. The FAA Capstone Program installed 
avionics and data link communications suites in 
aircraft serving Alaska to test new technologies. 
This system operated at 19.2 Kbps from and 3.6 
Kbps to the aircraft. 

Several higher bandwidth projects were being 
proposed at the time by Boeing, Tenzing & Hughes 
Global Services, AirTV, and the Airshow network. 
These indicated that bandwidth ranges from 
1.4Kbps to 1.5Mbps could be possible from the 
aircraft to the ground. They also indicated possible 
data rates from 144Kbps to 8Mbps from the ground 
to the aircraft. The high bandwidth capabilities 
demonstrated during the AeroSAPIENT research 
project indicated that data rates of 256Kbps from 
the plane and 2. 18Mbps to the airplane were 
feasible [1]. 

An example of bandwidth usage is useful to 
help illustrate the amount necessary to support 
various applications of interest. Here are some 
typical “real-life” examples: 

• Video/audio streaming server: 80Kbps 

• Voice over IP: 10Kbps 

• RTSS streaming video from the Half 
Moon Bay airport (video and 
environmental conditions such as 
temperature and due point): 720 Kbps 

Using these values, three video streams could 
saturate the entire data stream sent from the aircraft 
based on the AeroSAPIENT results. 


Other Factors 

There are other network related issues 
involved that could affect multiple-aircraft 
operations. These include limitations of the satellite 
technology. For example, transponders, which are 
microwave repeaters carried by communications 
satellites, are a limited resource. The 
AeroSAPIENT project used two separate 
transponders — one to transmit from the aircraft, and 
one to receive. In regards to operations with many 
aircraft at the same time, scalability will depend on 
the design and implementation of the total system, 
which will be a determining factor that impacts how 
much bandwidth will be available to each airplane. 

Other factors involve communications 
frequency choice, ambient weather conditions (rain 
and fog can hamper operations — some frequencies 
being more susceptible than others), and the 
selection of spread spectrum or narrow beam 
transmission. Transmission power is another factor. 

While these issues are important, they were not 
a major focus of our project and are beyond the 
scope of this paper. 

Bandwidth Limitations and 
Assumptions 

For this project, we were asked to work under 
a limitation of using a nominal ten percent of the 
total bandwidth (send and receive) made available 
by the AeroSAPIENT project. In emergency 
situations the amount could rise to 100%. The 
resulting values of 25.6 Kbps from and 218 Kbps to 
the aircraft were established for several reasons. 

First, our NASA Task Requestor foresaw that 
airlines would want to use the bandwidth to support 
profit-making opportunities and to improve service. 
Our future discussions with airline representatives 
supported this prediction. 

We also initially thought that bandwidth needs 
might vary during different phases of flight just as 
pilot worldoad does. For example, a higher amount 
of bandwidth might be used during takeoff and 
climb, less in cruise, and more during descent and 
landing. Although most of the applications we 
identified in our research would be used during 
cruise, we still feel that these phase-of-flight 
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differences in bandwidth usage w 11 bear out. These 
might be supported by some transmission 
technology other than the current satellite systems 
(for example, the transmission of high bandwidth 
data from terrestrial sites aligned with airport 
approach paths). 

We also came to the conclusion early in the 
research that an airline or data provider could 
“multicast” much of the data needed by many 
aircraft. A system on board the aircraft could tune 
to the specific data feed when needed. Data could 
also be collected and stored over time by an aircraft 
traveling in flight and used at the point it was 
required. 

We assumed that compression algorithms 
would be available to improve the transmission of 
this data. Where algorithms were available, we 
used them (for example, video compression 
algorithms), but we did not develop our own. 

Researching Stakeholder Needs 

A major goal of this project was to better 
understand who would use this new capability and 
how it would be used. We spoke with over 50 
individuals and groups within the aviation industry 
and airspace system. These included Airline pilots, 
cabin crew, operations, and maintenance personnel; 
ATC (Center, TRACON and Tower); Weather 
Providers and Flight Service personnel; and 
researchers from NASA Ames and Glenn. 

In the follow paragraphs we have summarized 
our identification of “needs”, from the perspective 
of each of these groups: 

Pilots 

The pilots we interviewed were primarily 
interested in getting additional “big picture” data 
which would allow them to see further ahead and 
around them in order to make better decisions 
during the flight. 

For example, on board weather radar can often 
yield a false picture of what is actually happening 
due to a storm cell which is close to the airplane 
blocking information about storm cells located 
further along, which may be far worse. They also 


felt that this information would enable better 
planning which would increase fuel efficiency by 
allowing pilots to re-route their course, if necessary, 
near the beginning of their flight, thereby allowing 
a more direct course. 

Pilots were also interested in using this system 
to enable better collaboration. An example might 
be that turbulence reports from other aircraft and 
the routes and altitudes they used to avoid 
turbulence could be shared more easily and quickly. 
Both pilots and cabin crew saw turbulence reporting 
as an important application, to include passenger 
comfort, safety, and a liability point of view. 

Pilots were also interested in gaining access to 
better maintenance reporting. They wanted to be 
able to speak directly with maintenance personnel, 
which would allow subtle issues or problems with 
an aircraft to be discussed in real time rather than 
through a limited number of fault codes. 

Cabin Crew 

The cabin crew also wanted direct access to 
warnings of reported or possible turbulence without 
having to get the data from the pilots. Advanced 
warnings would allow them to plan serving 
operations around rough weather, short term 
warnings would allow them to lock down serving 
carts several seconds before turbulence showed up. 

They also wanted the ability to report squawks 
(problems with the plane such as a seat that will not 
recline) directly to maintenance, and access to 
customer data (which connecting gate does the 
person in seat 14F need, once we arrive at 
Chicago?). 

Air Traffic Control: Center, TRACON, Tower 

ATC was satisfied with the information that 
they had for the most part, but wanted more 
accurate position, speed, and intent data. 

They also wanted a way of automatically 
verifying that a pilot has reviewed the ATIS 
information (which gives conditions and airport 
notices) for the airport of intended landing. 
Currently, if a pilot does not report having received 
the information, the air traffic controller must ask, 
and then either spend time informing the pilot of the 
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latest information or requesting that the pilot tune to 
another frequency and listen to it themselves. 

Flight Service Stations/Weather Providers 

Both saw the capability of installing weather 
sensors onboard each commercial aircraft would 
have a tremendous impact on the development of 
weather models, especially for long flights 
overseas. These sensors could be programmed to 
record and download data at specific millibar levels. 
Currently, weather balloons are still the primary 
method of sensing this data from the environment. 

Airline Industry 

In talking with industry representatives, our 
thoughts that airline management needs to see a 
financial incentive in order to implement this 
technology were verified. Their first target 
involved revenue-enhancing applications, such as 
email or web surfing at a premium, for their 
passengers. Maintenance and flight operation 
enhancements were next, followed by cockpit 
enhancements. They also saw the value of 
collecting weather data with their aircraft, both for 
increasing safety and as a possible revenue stream. 

At the time that we talked with them (August, 
2001), at least one airline was in the process of 
developing an infrastructure to support broadband 
into their fleet. They were looking at how 
transponders, ground support and phased array 
antennas would be used to support the above 
applications. They also were in discussions with 
both Boeing and Airbus on how this hardware 
would be integrated. Several other airlines were 
interested in their system Benefit Areas 

Based on this research, we identified three 
major areas where we felt we should focus our 
development to provide the greatest benefits. 

Providing Relevant Information 

The first area was to provide relevant 
information to the user. This would not be raw 
data, but would be in a form that w ould allow easy 
integration providing knowledge. At the same time, 
overwhelming the user with too much information 
is a problem that should be avoided. 


Enhancing Collaboration 

The second area was to provide ways of 
enhancing collaboration. This involved the ability 
to bring all the players and data together to more 
easily solve problems. 

Collaboration in aviation operations exists 
currently in many forms. But it involves low 
bandwidth, inefficient user interfaces, and slow or 
spotty turn around times. 

Enhancing Existing Interfaces 

The third benefit area we identified was to 
provide relevant interfaces to the information. This 
would be to provide interfaces to the user that were 
easy to use and navigate. We were interested in 
investigating interfaces that would be easy to 
integrate or retrofit into existing work areas such as 
voice control, PDAs, and wireless technology. 

Developing a Simulation Platform 

In parallel with this research, we worked to 
develop a flight simulation environment in which to 
demonstrate ideas. Given that we had limited time 
and budget available, we focused on what other 
researchers were using and COTS (commercial off 
the shelf) simulators. 

Our initial requirements for a flight simulator 
included having an open programming interface, an 
out the window view, the ability to retrieve real- 
time weather data, the ability to portray weather 
conditions in the out the window view, and the 
ability to enter and follow a flight plan for a demo 
scenario. 

After reviewing many simulation platforms, 
we decided upon Microsoft flight simulator 2000 as 
the basis for our simulator. We enhanced it with 3 rd 
party networking software (the FSUIPC utility 
developed by Peter Dowson). We also integrated a 
separate package called Project Magenta, which 
provides an enhanced MCP (mode control panel), 
FMS (flight management system), and glass cockpit 
displays. This combination provided an adequate 
simulation environment with a realistic out the 
window view, and also enabled us to write our own 
programs to extract data, (for example, position or 
airspeed), from the simulator while flying it. This 
interface would also allow us to link the simulator 
with other applications (for example, an Airline 
Operations Center) via TCP/IP networking. 
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Application Focus Areas 

Based on the results of our stakeholder needs 
analysis, we felt that improvements in cockpit 
operations, and better interaction with Airline 
Operations Center (AOC) were application areas 
where we should focus our development. 

We further refined our demonstration 
applications areas to Cockpit Weather and Traffic, 
and Cockpit Monitoring and Control. Both 
included significant interaction with AOC 
operations. 

Cockpit Weather and Traffic 

Motivation 

From our discussions with commercial pilots, 
we learned that the AOC, which is the airline’s 
ground support team, can often become overloaded 
and are not able to answer pilot's queries for 
information. This can occur when there is 
significant weather in play or there is a problem 
with another aircraft. 

By providing pilots with access to a display of 
the current weather and the locations of other 
aircraft similar to that of the AOC. we felt that we 
could offload the reliance on the AOC and at the 
same time, could enable the improvement of local 
and strategic decision making. For example, pilots 
could determine the best route to Boston after 
taking off from San Francisco by knowing early on 
where bad weather systems are located and also by 
observing where other traffic is going: they could 
avoid areas which will be greatly impacted with 
aircraft trying to avoid the same weather systems. 

Development 

To provide weather and traffic for this 
application we teamed with RLM of Boston, MA. 
We used RLM’s FlightView product, which 
displays traffic and weather throughout the US and 
Canada. A user can easily zoom and pan around 
the display to focus in on an area of interest. An 
example of the flight view display is shown in 
Figure 1. In this application, we ran a copy of the 
Flight View application in both the cockpit and 
AOC station. 


For this application, we reconfigured the 
Microsoft flight simulator program to suppress the 
display of cockpit gauges in order to maximize the 
out the window view. Figure 2 shows a typical 
display from this application as configured. 

We used the FSUIPC and WideFS utilities 
developed by Peter Dowson to extend the 
networking capabilities of Microsoft Flight 
Simulator. These utilities allowed us to interface 



Figure 1. RLM Flight View Weather and Traffic 
Display. 



Figure 2. Microsoft Flight Simulator Out the 
Window Display. 


the simulator across an Ethernet network with 
another PC that represented the AOC station. We 
used this to simulate the high bandwidth satellite 
connection between the aircraft and the ground. 


5 


Using this software, a dynamic link library was 
developed at NASA that allowed applications to 
read the location, heading and altitude of the flight 
simulator off of the network. The RLM engineers 
integrated this software into their FlightView 
software, which then allowed this program to 
display a real-time update of the laboratory flight 
simulator in the live traffic and weather display. 
Figure 3 shows the resulting architecture of this 
integrated system. 



Figure 3. Cockpit Weather and Traffic 
Application Architecture. 


Results 

The bandwidth requirements of this system 
were minimal at about 3Kbps upload and less than 
1Kbps download. This rate provided a traffic 
update every 3 minutes and the weather every 6 
minutes, which was the update limit of the 
Flightview application. At this low bandwidth, this 
would be a candidate application for multicasting to 
all aircraft in a fleet over a single transponder. 

Directions for Further Development 

We have several ideas for the further 
development of this application of real time weather 
and traffic display in the cockpit. 

• Integrate additional weather products 
such as high resolution Doppler radar, 
upper level winds and other data into 
the display. 

• Verify through human factors studies 
that the additional data actually 
improves situational awareness and 


lower the overall cost of flights, 
individually or in collaboration with the 
AOC. 

• Provide ways for the AOC to annotate 
and enhance data presented in the 
aircraft cockpit (strategic collaboration). 

• Model the downloading of weather data 
from the aircraft to support the 
development of more accurate models 
of weather and the atmosphere. 

• Investigate new interfaces, such as 
voice or visual, for the display of data. 


AOC Monitoring and Control 

Motivation 

The events of September 1 1 * were a 
motivating factor in developing an application that 
would provide an AOC with the ability to monitor 
the health of an aircraft and crew in flight. We 
wanted to provide the capability for the AOC to 
take over and control the aircraft. We also felt that 
this would be a better test of bandwidth capabilities. 

Our motivation to provide cockpit monitoring 
and control came from reports that detailed what 
happened during the takeover of the four aircraft. 
The AOCs sensed that there was a problem but had 
no way of verifying what the problem was. United 
Airlines and American Airlines AOCs collaborated 
and reacted quickly to ground their fleets before any 
orders from the FAA. 

We were interested in collecting multiple 
streams of data and providing these to the ground. 
The streams should also complement themselves 
and allow the discrimination of false indications. 

We felt that aircraft telemetry (speed, position, 
heading); video (cockpit and cabin); and pilot 
health (pulse rate, blood pressure) were the data 
streams necessary to fully monitor the state of the 
aircraft and crew. 

A further motivation to develop this 
application is that it would allow us to investigate 
control station concepts for unmanned aerial 
vehicles (UAVs) and space assets such as the 
personal satellite assistant (PSA), space station, and 
future spacecraft. These systems also have the need 
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to provide multiple streams of data (aircraft health, 
multiple sensors and video data), so the resultant 
architecture might be a good match. 


Development 

We built upon the architecture developed for 
the Cockpit weather and Traffic Application. We 
continued to use Flight View on both the cockpit 
and AOC applications as previously supported by 
the FSU1PC and WideFS network utilities. 


Remote Cockpit Instruments and Control 

We used a plug in to Microsoft Flight 
Simulator called Project Magenta, developed by 
Enrico Schiratti. This package provides a 
networked architecture that allows multiple cockpit 
applications, (for example, cockpit instruments, 
throttles, mode control panel (MCP), and flight 
management system (FMS)) to send and receive 
information from the flight simulator. These 
applications can be co resident or distributed across 
computers on a network. 



Figure 4. AOC Flight Instrument and Control 
Display. 

Figure 4 shows the flight instrument and control 
interface that was provided at the AOC station. It 
consists of a Mode Control Panel, Primary and 
Navigation displays, Engine Instruments, and a 
Control Display interface to the Flight Management 
system. This interface is fully capable of 
controlling the aircraft simulator remotely. 

Cockpit Video Feed 

We next integrated a video camera into the 
system. We used a USB camera installed on a PC 


and used a Sorenson video server to transmit the 
data to the AOC station via the network. This 
camera was used to provide an out the window 
view for landing the aircraft. To simulate this 
video, we positioned the camera so that it was 
focused on the out the window view display from 
Microsoft Flight simulator. The output of this at the 
AOC station can be seen at the bottom of figure 4. 

We also wanted to be able to provide 
simulated cockpit and cabin views to the AOC that 
would be selectable. In practice, multiple cameras 
under a selectable feed could have handled this 
functionality. For expediency we chose to provide 
a second video feed of the cabin area using the 
video provided by the Smart Healthcare 
Management System described below. 


Monitoring Pilot Health 

We wanted to be able to provide a non- 
invasive monitoring capability of the health (stress 
or workload) of the pilot. Pulse rate has been found 
to be a good measure of pilot workload [4] and 
should be easy to measure. We investigated many 
systems, including PC based blood pressure 
monitors, and a pulse rate monitor developed by the 
Hewlett Packard Palo Alto Research Lab. We 
eventually found the best solution here at Ames 
from the Smart Healthcare Management Systems 
Team, Astrobionics Division. 



Figure 5. AOC Weather and Pilot Monitoring 
Displays. 
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Figure 6. Application Architecture for the Cockpit Monitoring and Control Application. 


This system has been under development for 
several years. Its goal is to provide the capability of 
remotely monitoring primarily human vital signs 
via wireless and other networked links. They have 
developed a specialized monitoring sensor package 
that can be adhered to a user’s body, or could easily 
be built into a seat. It is also capable of integrating 
data from any type of telemetry stream, for example 
engine or fire monitoring. 

The system software is portable and is capable 
of running on most platforms. It was used by our 
application running on a Compaq IPAQ computer 
that provided blood pressure, heart rate, and cockpit 
video over a wireless network to our AOC station. 
Figure 5 shows the second AOC computer display 


with the Flight View application in the upper left 
and the Smart Healthcare Display in the lower right. 

Results 

Figure 6 shows the full implementation of the 
AOC Monitoring and Control simulation including 
the applications and their distribution among the 
computers. 

Figure 7 shows a diagram that summarizes the 
bandwidth requirements of the Cockpit Monitoring 
and Control Application. Recall that this 
application subsumes the work developed in the 
Cockpit Weather Application. 
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Aircraft Control Bandwidth: 

Downlink from plane: 
170x30fps = 5.1 kbps 


FLIGHT SIMULATOR 

Telemetry 


Control 


Uplink to plane: 
54x30fps= 1.62 kbps 


Video Bandwidth: 


Sorenson: 6fps, 80 kbps 
SmartMed: 8fps, 642 kbps 


FllghtView Bandwidth: 

(Flight updates every 3 minutes, weather 
every 5 minutes) 

3 kbps 


SmartMed Bandwidth: 
3 kbps 


TOTAL BANDWIDTH: 
Downlink: 730 kbps 
Uplink: 5kbps 
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ground speed 4 bytes 
True Airspeed 4 bytes 
inicated Airspeed 4 bytes 
heading 4 bytes 
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Engine 
N2 4 bytes 
Fuel flow 4 bytes 
Oil Pressure 4 bytes 
Oil Temperature 4 bytes 
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Vibration 8 bytes 
Fuel Qty 8 bytes 
Expansion 40 bytes 


Gear 4 bytes 
Flaps 4 bytes 
Flight controls 
Elevator Axis 2 bytes 
Aileron Axis 2 bytes 
Rudder Axis 2 bytes 
Throttle Axis 10 bytes 
Expansion 30 bytes 
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Figure 7. Bandwidth Requirements of the Cockpit Monitoring and Control Application. 


This diagram provides a total bandwidth 
requirement under emergency conditions (all 
telemetry, video and control links active) of 730 
Kbps downlink and 5 Kbps uplink. 

Recall that our target values under nominal 
conditions were 25.6 Kbps downlink and 218 Kbps 
uplink, and up to 256Kbps downlink and 2.18Mbps 
uplink available during emergency operations. In 


this configuration, we far exceeded our limits, but 
there are several factors that would bring this 
bandwidth usage into reason. 

Because of time and funding limitations we 
chose to use the video from the Smart Heathcare 
System without compression for in cockpit video. 
We feel that if we were to have used Sorenson 
compression on this data, we could have reduced its 
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value from 642 Kbps down to something in the 
order of 80 Kbps. This would have brought our 
total down to approximately 170 Kbps in an 
emergency configuration, which would have been 
well within our limits. 

If we were just monitoring the health of the 
aircraft and pilots, this value would have been 
within our limits at 8Kbps. Also, we feel that there 
may be additional opportunities to reduce the 
bandwidth by adjusting update rates, or actively 
controlling which streams have priority in different 
modes (for example, cockpit video would have less 
priority in comparison with out the window video 
during landing operations). 

Further Directions 

In developing this application, we identified 
several directions in which this system could be 
expanded to provide additional capabilities. 

Smart Monitoring and Alert 

To reduce the amount of data that would need 
to be continually downloaded from each aircraft, an 
on board system could be developed that would 
actively monitor the aircraft and cabin data streams. 
It could also be able discern when , for example, 
extraneous movement in the cabin, a high pulse rate 
from the pilot, and deviations of course might 
indicate a possible hijacking or an explosive 
decompression. The system would notify the AOC 
and institute a higher bandwidth connection only 
when a non-nominal situation was thought to exist. 

In place, this would allow a much smaller 
stream of continuous data (indicating that 
conditions were nominal) to be sent to the AOC, 
allowing many aircraft to be monitored via a single 
satellite transponder. 

Active Streaming 

It is also possible that the data return capability 
of the aircraft could improve through the use of 
alternative technology. This would include both 
“black-box” information, as well as more advanced 
data such as streaming video of what is going on in 
the cockpit. In discussions with fellow researchers 
after the September 1 1 th incident, there was an 
interest in showing not only how an incident 


happened, but also the prior 10 minutes leading up 
to it. 

This data could be continually stored on tape 
or disk in a black box. However, it was brought to 
our attention by Robert Pap of the Accurate 
Automation Corporation that “15 of the last 16 
commercial aircraft that have crashed have included 
satellite communications equipment.” When a 
problem occurred, this archived data (the last 10 
minutes) could be broadcast at some rate over a 
satellite or aviation specific wireless networks. 

This data could also be interwoven with real time 
video data. 


Integrated Controls 

The cockpit control interface that we 
implemented in our AOC simulation was the same 
interface as that of a commercial aircraft. This 
interface is quite obvious to commercial pilots but 
might not be as obvious to a pilot not current on 
that aircraft or to all AOC personnel. If this 
interface were implemented it would require a pilot 
be on staff at all times at that facility. Alternatively, 
it would require the capability of transferring the 
control feed to a different facility where a pilot 
current on that aircraft was available. 

To work around this requirement, it should be 
possible to develop an interface that would allow 
simpler goal-based text, graphical, or voice 
commands (for example, fly to this waypoint and 
hold) to be used. This interface would translate 
those commands into those that the specific aircraft 
autopilot under control would understand and 
follow. This interface would be essential under a 
mixed fleet situation (for example, an airline with 
both Boeing and Airbus aircraft) or could also be 
used to control multiple UAV assets. 

Uses of Additional Uplink Data 

In the development of these applications, we 
were able to fully saturate the channel containing 
the data coming from the aircraft, but were not able 
to fully utilize the uplink channel, even though it 
had much more capability. From what we have 
learned, this was acceptable, because the limited 
number of transponders available would force the 
sharing of this resource through the multicast of 
data to many aircraft. 
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However, additional research is necessary to 
investigate what applications to pi lots and other 
aviation stakeholders could use more of this 
channel under emergency conditions. This would 
include both the applications and t he phase of flight 
in which they would be used. 

Summary 

In the BEFO project, we researched and 
identified applications of high bandwidth data in 
commercial aviation. We also worked to gain a 
better understanding of the available bandwidth and 
how it could be applied in this env ironment. In the 
process, we identified and worked with several 
teaming partners. We were able to develop a high- 
bandwidth simulation architecture and 
demonstrated it on two sample applications. We 
identified several areas where these applications 
could be expanded to support additional 
functionality. We are interested in expanding this 
work to investigate and evaluate technologies that 
can be applied to commercial flight, UAV and 
space applications. 
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